写在开篇

Service Worker 是 Chrome Extension 的大脑，只有对 Service Worker 足够了解，才能更好的应用 Chrome Extension。

本文，将持续记录“关于 Service Worker 的一些小细节”。

一个插件的 Service Worker 本身

1. 每个 Chrome Extension 拥有一个 Service Worker；

2. 可以在 Service Worker 中向 IndexDB 中存储数据，但是无法在后台界面中看到，只能用代码存取；

3. 在 manifest.json 文件中设置的 JS 文件会在 Service Worker 每次启动、休眠后重启时 都会执行一次；

这是一个十分重要的细节点。如果有一些在执行这个文件时需要设置的持久性数据的，请务必做好唯一性校验工作；

4. 经过实践测试，Service Worker 休眠后的这些内容会被清除（重要！重要！！重中之重！！！）:

内存变量[全局变量]；

监听函数：

chrome.webRequest.onBeforeSendHeaders.addListener 设置的监听函数；

动态请求头设置规则：

chrome.declarativeNetRequest.updateDynamicRules 设置的变动规则；

chrome.declarativeNetRequest.updateSessionRules 设置的请求规则；【2025.6.4更新，该规则数据在浏览器关闭、更新时清除】

为什么特别指明“全局变量”？是因为开发者手册中可以找到原文引用，且用户需要注意在适当时候使用持久性缓存方案：

Any global variables you set will be lost if the service worker shuts down. Instead of using global variables, save values to storage.

chrome.declarativeNetRequest.updateSessionRules 设置的请求头更新规则在用户手册中找到原文：

Session rules are cleared when the browser shuts down and when a new version of the extension is installed.

多个插件的 Service Worker 之间

1. 每个 Chrome Extension 拥有一个 Service Worker，但多个 Chrome Extension 的 Service Worker 环境是相互隔离的;

一个插件的 Content 层与 Service Worker

1. Content 与 Service Worker 是 N-1 的关系;

即，针对一个插件来说，当我们打开多个 TAB（Content层）时，多个 Content 层都在与同一个 Service Worker 交互。

这里就要注意：当由 Content 触发 Service Worker 层的执行与数据设置时，务必做好唯一性校验；

2. Content 与 Service Worker 建立长链接通信通道时，会唤醒休眠的 Service Worker;

这里有个 最佳实践（交互） ：监听长链接通信通道的断联时机，在断联时，重新创建长链接通信通道，就可以实现：用户不刷新 TAB 页面的情况下，唤醒 Service Worker，从而达到“随时可以使用插件”的目的。

写在最后

Service Worker 与 插件的其他部件 有关的通信资料 请参阅《Chrome Extension通信相关（汇总）》、《关于Chrome Extension option的一些小事》。

本节内容皆为实践测试所得，如有不够严谨的地方，请指正，另外，本文会在后续实践中持续更新，敬请关注～